home *** CD-ROM | disk | FTP | other *** search
/ Ian & Stuart's Australian Mac: Not for Sale / Another.not.for.sale (Australia).iso / fade into you / being there / Rants / rfc1591.Domains < prev    next >
Text File  |  1993-01-01  |  16KB  |  396 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                          J. Postel
  8. Request for Comments: 1591                                           ISI
  9. Category: Informational                                       March 1994
  10.  
  11.  
  12.               Domain Name System Structure and Delegation
  13.  
  14.  
  15. Status of this Memo
  16.  
  17.    This memo provides information for the Internet community.  This memo
  18.    does not specify an Internet standard of any kind.  Distribution of
  19.    this memo is unlimited.
  20.  
  21. 1. Introduction
  22.  
  23.    This memo provides some information on the structure of the names in
  24.    the Domain Name System (DNS), specifically the top-level domain
  25.    names; and on the administration of domains.  The Internet Assigned
  26.    Numbers Authority (IANA) is the overall authority for the IP
  27.    Addresses, the Domain Names, and many other parameters, used in the
  28.    Internet.  The day-to-day responsibility for the assignment of IP
  29.    Addresses, Autonomous System Numbers, and most top and second level
  30.    Domain Names are handled by the Internet Registry (IR) and regional
  31.    registries.
  32.  
  33. 2.  The Top Level Structure of the Domain Names
  34.  
  35.    In the Domain Name System (DNS) naming of computers there is a
  36.    hierarchy of names.  The root of system is unnamed.  There are a set
  37.    of what are called "top-level domain names" (TLDs).  These are the
  38.    generic TLDs (EDU, COM, NET, ORG, GOV, MIL, and INT), and the two
  39.    letter country codes from ISO-3166.  It is extremely unlikely that
  40.    any other TLDs will be created.
  41.  
  42.    Under each TLD may be created a hierarchy of names.  Generally, under
  43.    the generic TLDs the structure is very flat.  That is, many
  44.    organizations are registered directly under the TLD, and any further
  45.    structure is up to the individual organizations.
  46.  
  47.    In the country TLDs, there is a wide variation in the structure, in
  48.    some countries the structure is very flat, in others there is
  49.    substantial structural organization.  In some country domains the
  50.    second levels are generic categories (such as, AC, CO, GO, and RE),
  51.    in others they are based on political geography, and in still others,
  52.    organization names are listed directly under the country code.  The
  53.    organization for the US country domain is described in RFC 1480 [1].
  54.  
  55.  
  56.  
  57.  
  58. Postel                                                          [Page 1]
  59.  
  60. RFC 1591      Domain Name System Structure and Delegation     March 1994
  61.  
  62.  
  63.    Each of the generic TLDs was created for a general category of
  64.    organizations.  The country code domains (for example, FR, NL, KR,
  65.    US) are each organized by an administrator for that country.  These
  66.    administrators may further delegate the management of portions of the
  67.    naming tree.  These administrators are performing a public service on
  68.    behalf of the Internet community.  Descriptions of the generic
  69.    domains and the US country domain follow.
  70.  
  71.    Of these generic domains, five are international in nature, and two
  72.    are restricted to use by entities in the United States.
  73.  
  74.    World Wide Generic Domains:
  75.  
  76.    COM - This domain is intended for commercial entities, that is
  77.          companies.  This domain has grown very large and there is
  78.          concern about the administrative load and system performance if
  79.          the current growth pattern is continued.  Consideration is
  80.          being taken to subdivide the COM domain and only allow future
  81.          commercial registrations in the subdomains.
  82.  
  83.    EDU - This domain was originally intended for all educational
  84.          institutions.  Many Universities, colleges, schools,
  85.          educational service organizations, and educational consortia
  86.          have registered here.  More recently a decision has been taken
  87.          to limit further registrations to 4 year colleges and
  88.          universities.  Schools and 2-year colleges will be registered
  89.          in the country domains (see US Domain, especially K12 and CC,
  90.          below).
  91.  
  92.    NET - This domain is intended to hold only the computers of network
  93.          providers, that is the NIC and NOC computers, the
  94.          administrative computers, and the network node computers.  The
  95.          customers of the network provider would have domain names of
  96.          their own (not in the NET TLD).
  97.  
  98.    ORG - This domain is intended as the miscellaneous TLD for
  99.          organizations that didn't fit anywhere else.  Some non-
  100.          government organizations may fit here.
  101.  
  102.    INT - This domain is for organizations established by international
  103.          treaties, or international databases.
  104.  
  105.    United States Only Generic Domains:
  106.  
  107.    GOV - This domain was originally intended for any kind of government
  108.          office or agency.  More recently a decision was taken to
  109.          register only agencies of the US Federal government in this
  110.          domain.  State and local agencies are registered in the country
  111.  
  112.  
  113.  
  114. Postel                                                          [Page 2]
  115.  
  116. RFC 1591      Domain Name System Structure and Delegation     March 1994
  117.  
  118.  
  119.          domains (see US Domain, below).
  120.  
  121.    MIL - This domain is used by the US military.
  122.  
  123.    Example country code Domain:
  124.  
  125.    US - As an example of a country domain, the US domain provides for
  126.         the registration of all kinds of entities in the United States
  127.         on the basis of political geography, that is, a hierarchy of
  128.         <entity-name>.<locality>.<state-code>.US.  For example,
  129.         "IBM.Armonk.NY.US".  In addition, branches of the US domain are
  130.         provided within each state for schools (K12), community colleges
  131.         (CC), technical schools (TEC), state government agencies
  132.         (STATE), councils of governments (COG),libraries (LIB), museums
  133.         (MUS), and several other generic types of entities (see RFC 1480
  134.         for details [1]).
  135.  
  136.    To find a contact for a TLD use the "whois" program to access the
  137.    database on the host rs.internic.net.  Append "-dom" to the name of
  138.    TLD you are interested in.  For example:
  139.  
  140.                        whois -h rs.internic.net us-dom
  141.       or
  142.                        whois -h rs.internic.net edu-dom
  143.  
  144. 3.  The Administration of Delegated Domains
  145.  
  146.    The Internet Assigned Numbers Authority (IANA) is responsible for the
  147.    overall coordination and management of the Domain Name System (DNS),
  148.    and especially the delegation of portions of the name space called
  149.    top-level domains.  Most of these top-level domains are two-letter
  150.    country codes taken from the ISO standard 3166.
  151.  
  152.    A central Internet Registry (IR) has been selected and designated to
  153.    handled the bulk of the day-to-day administration of the Domain Name
  154.    System.  Applications for new top-level domains (for example, country
  155.    code domains) are handled by the IR with consultation with the IANA.
  156.    The central IR is INTERNIC.NET.  Second level domains in COM, EDU,
  157.    ORG, NET, and GOV are registered by the Internet Registry at the
  158.    InterNIC.  The second level domains in the MIL are registered by the
  159.    DDN registry at NIC.DDN.MIL.  Second level names in INT are
  160.    registered by the PVM at ISI.EDU.
  161.  
  162.    While all requests for new top-level domains must be sent to the
  163.    Internic (at hostmaster@internic.net), the regional registries are
  164.    often enlisted to assist in the administration of the DNS, especially
  165.    in solving problems with a country administration.  Currently, the
  166.    RIPE NCC is the regional registry for Europe and the APNIC is the
  167.  
  168.  
  169.  
  170. Postel                                                          [Page 3]
  171.  
  172. RFC 1591      Domain Name System Structure and Delegation     March 1994
  173.  
  174.  
  175.    regional registry for the Asia-Pacific region, while the INTERNIC
  176.    administers the North America region, and all the as yet undelegated
  177.    regions.
  178.  
  179.       The contact mailboxes for these regional registries are:
  180.  
  181.          INTERNIC        hostmaster@internic.net
  182.          APNIC           hostmaster@apnic.net
  183.          RIPE NCC        ncc@ripe.net
  184.  
  185.    The policy concerns involved when a new top-level domain is
  186.    established are described in the following.  Also mentioned are
  187.    concerns raised when it is necessary to change the delegation of an
  188.    established domain from one party to another.
  189.  
  190.    A new top-level domain is usually created and its management
  191.    delegated to a "designated manager" all at once.
  192.  
  193.    Most of these same concerns are relevant when a sub-domain is
  194.    delegated and in general the principles described here apply
  195.    recursively to all delegations of the Internet DNS name space.
  196.  
  197.    The major concern in selecting a designated manager for a domain is
  198.    that it be able to carry out the necessary responsibilities, and have
  199.    the ability to do a equitable, just, honest, and competent job.
  200.  
  201.    1) The key requirement is that for each domain there be a designated
  202.       manager for supervising that domain's name space.  In the case of
  203.       top-level domains that are country codes this means that there is
  204.       a manager that supervises the domain names and operates the domain
  205.       name system in that country.
  206.  
  207.       The manager must, of course, be on the Internet.  There must be
  208.       Internet Protocol (IP) connectivity to the nameservers and email
  209.       connectivity to the management and staff of the manager.
  210.  
  211.       There must be an administrative contact and a technical contact
  212.       for each domain.  For top-level domains that are country codes at
  213.       least the administrative contact must reside in the country
  214.       involved.
  215.  
  216.    2) These designated authorities are trustees for the delegated
  217.       domain, and have a duty to serve the community.
  218.  
  219.       The designated manager is the trustee of the top-level domain for
  220.       both the nation, in the case of a country code, and the global
  221.       Internet community.
  222.  
  223.  
  224.  
  225.  
  226. Postel                                                          [Page 4]
  227.  
  228. RFC 1591      Domain Name System Structure and Delegation     March 1994
  229.  
  230.  
  231.       Concerns about "rights" and "ownership" of domains are
  232.       inappropriate.  It is appropriate to be concerned about
  233.       "responsibilities" and "service" to the community.
  234.  
  235.    3) The designated manager must be equitable to all groups in the
  236.       domain that request domain names.
  237.  
  238.       This means that the same rules are applied to all requests, all
  239.       requests must be processed in a non-discriminatory fashion, and
  240.       academic and commercial (and other) users are treated on an equal
  241.       basis.  No bias shall be shown regarding requests that may come
  242.       from customers of some other business related to the manager --
  243.       e.g., no preferential service for customers of a particular data
  244.       network provider.  There can be no requirement that a particular
  245.       mail system (or other application), protocol, or product be used.
  246.  
  247.       There are no requirements on subdomains of top-level domains
  248.       beyond the requirements on higher-level domains themselves.  That
  249.       is, the requirements in this memo are applied recursively.  In
  250.       particular, all subdomains shall be allowed to operate their own
  251.       domain name servers, providing in them whatever information the
  252.       subdomain manager sees fit (as long as it is true and correct).
  253.  
  254.    4) Significantly interested parties in the domain should agree that
  255.       the designated manager is the appropriate party.
  256.  
  257.       The IANA tries to have any contending parties reach agreement
  258.       among themselves, and generally takes no action to change things
  259.       unless all the contending parties agree; only in cases where the
  260.       designated manager has substantially mis-behaved would the IANA
  261.       step in.
  262.  
  263.       However, it is also appropriate for interested parties to have
  264.       some voice in selecting the designated manager.
  265.  
  266.       There are two cases where the IANA and the central IR may
  267.       establish a new top-level domain and delegate only a portion of
  268.       it: (1) there are contending parties that cannot agree, or (2) the
  269.       applying party may not be able to represent or serve the whole
  270.       country.  The later case sometimes arises when a party outside a
  271.       country is trying to be helpful in getting networking started in a
  272.       country -- this is sometimes called a "proxy" DNS service.
  273.  
  274.       The Internet DNS Names Review Board (IDNB), a committee
  275.       established by the IANA, will act as a review panel for cases in
  276.       which the parties can not reach agreement among themselves.  The
  277.       IDNB's decisions will be binding.
  278.  
  279.  
  280.  
  281.  
  282. Postel                                                          [Page 5]
  283.  
  284. RFC 1591      Domain Name System Structure and Delegation     March 1994
  285.  
  286.  
  287.    5) The designated manager must do a satisfactory job of operating the
  288.       DNS service for the domain.
  289.  
  290.       That is, the actual management of the assigning of domain names,
  291.       delegating subdomains and operating nameservers must be done with
  292.       technical competence.  This includes keeping the central IR (in
  293.       the case of top-level domains) or other higher-level domain
  294.       manager advised of the status of the domain, responding to
  295.       requests in a timely manner, and operating the database with
  296.       accuracy, robustness, and resilience.
  297.  
  298.       There must be a primary and a secondary nameserver that have IP
  299.       connectivity to the Internet and can be easily checked for
  300.       operational status and database accuracy by the IR and the IANA.
  301.  
  302.       In cases when there are persistent problems with the proper
  303.       operation of a domain, the delegation may be revoked, and possibly
  304.       delegated to another designated manager.
  305.  
  306.    6) For any transfer of the designated manager trusteeship from one
  307.       organization to another, the higher-level domain manager (the IANA
  308.       in the case of top-level domains) must receive communications from
  309.       both the old organization and the new organization that assure the
  310.       IANA that the transfer in mutually agreed, and that the new
  311.       organization understands its responsibilities.
  312.  
  313.       It is also very helpful for the IANA to receive communications
  314.       from other parties that may be concerned or affected by the
  315.       transfer.
  316.  
  317. 4. Rights to Names
  318.  
  319.    1) Names and Trademarks
  320.  
  321.       In case of a dispute between domain name registrants as to the
  322.       rights to a particular name, the registration authority shall have
  323.       no role or responsibility other than to provide the contact
  324.       information to both parties.
  325.  
  326.       The registration of a domain name does not have any Trademark
  327.       status.  It is up to the requestor to be sure he is not violating
  328.       anyone else's Trademark.
  329.  
  330.    2) Country Codes
  331.  
  332.       The IANA is not in the business of deciding what is and what is
  333.       not a country.
  334.  
  335.  
  336.  
  337.  
  338. Postel                                                          [Page 6]
  339.  
  340. RFC 1591      Domain Name System Structure and Delegation     March 1994
  341.  
  342.  
  343.       The selection of the ISO 3166 list as a basis for country code
  344.       top-level domain names was made with the knowledge that ISO has a
  345.       procedure for determining which entities should be and should not
  346.       be on that list.
  347.  
  348. 5. Security Considerations
  349.  
  350.    Security issues are not discussed in this memo.
  351.  
  352. 6. Acknowledgements
  353.  
  354.    Many people have made comments on draft version of these descriptions
  355.    and procedures.  Steve Goldstein and John Klensin have been
  356.    particularly helpful.
  357.  
  358. 7. Author's Address
  359.  
  360.    Jon Postel
  361.    USC/Information Sciences Institute
  362.    4676 Admiralty Way
  363.    Marina del Rey, CA  90292
  364.  
  365.    Phone: 310-822-1511
  366.    Fax:   310-823-6714
  367.    EMail: Postel@ISI.EDU
  368.  
  369. 7. References
  370.  
  371.    [1] Cooper, A., and J. Postel, "The US Domain", RFC 1480,
  372.        USC/Information Sciences Institute, June 1993.
  373.  
  374.    [2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340,
  375.        USC/Information Sciences Institute, July 1992.
  376.  
  377.    [3] Mockapetris, P., "Domain Names - Concepts and Facilities", STD
  378.        13, RFC 1034, USC/Information Sciences Institute, November 1987.
  379.  
  380.    [4] Mockapetris, P., "Domain Names - Implementation and
  381.        Specification", STD 13, RFC 1035, USC/Information Sciences
  382.        Institute, November 1987.
  383.  
  384.    [6] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC
  385.        974, CSNET CIC BBN, January 1986.
  386.  
  387.    [7] Braden, R., Editor, "Requirements for Internet Hosts --
  388.        Application and Support", STD 3, RFC 1123, Internet Engineering
  389.        Task Force, October 1989.
  390.  
  391.  
  392.  
  393.  
  394. Postel                                                          [Page 7]
  395.  
  396.